AltME groups: search

Louis; do yourself a favour.  Read up on chmod, chown and chgrp. 
 In particular chmod.  These aren't the easiest of topics at first 
(mainly due to the crap involved with the 1970's octal numbers and 
some poor choice of names).   But after the initial weirdness the 
concepts are really straight forward.  Read, Write, Execute across 
User (the owner), Group, Others (not in group) and All (world).


There is an overlay of weirdness with directories and Execute (create 
a file in the dir) and a special mode bit etc.  But again ... grunt 
through until your brain tells you that you get it.  It's important, 
imho.


Flailing around with sudo and su (and root powers in general) is 
not the safest of ways to run Linux.  Potentially lowers the security 
to the level of your average Windows box ... nearly none.  :)    
 It can seem like a pain sometimes, but it isn't, it's part and parcel 
of a secure os.  BG has tainted the world to think it is inconvenient. 
Much like a lock maker giving everyone the same key.  A stupid "convenience" 
that wouldn't fly when it came to your car or house or bank, but 
PC users have grown up with and expect for reasons I have never understood. 
 (This last part is simple ranting - sorry about that)

On the twiki site http://twiki.org/cgi-bin/view/Plugins/GenPDFLatexAddOn

I found this

#  Setup the Latex rendering software


    * Ensure that a latex document preparation system is available to 
    the user name (uid) running the twiki web server.

    * Install any custom latex style files needed. The best suggestion 
    is to create a local texmf tree accessible by the server. For example, 
    for an apache server running as 'nobody' on a linux system:

          o create the directory /home/nobody/texmf/tex/latex, with reasonable 
          permissions.

          o Place the custom .cls and .sty latex files in this directory

          o as user root or nobody, run texhash /home/nobody/texmf to create 
          the ls-R latex database file for the /home/nobody/texmf/ tree.

The browser as the launch platform for applications has always been 
an interesting idea. The fundamental problem of the sheer complexity 
of it can be solved with R3. If done right, it can completely wipe 
the floor with browsers and AJAX. I think the problem is that we 
haven't been speaking in a language that people can understand, such 
as "browser", "web2.0" and "webserver", but instead "dialects", "VID", 
"Viewtop" and "X Internet" and people go "huh?".

Some things I believe are needed to do this right:


- Browser form factor. People are used to browsers, not Viewtops. 
What's always the first thing a complete newbie computer user uses, 
when wanting to do anything on the internet? A webbrowser. I don't 
want a desktop inside my desktop. There are tens of solutions for 
such things and they are almost all forgotten. Carl is doing the 
REBOL browser. When you fire up R3, you will get what looks like 
a webbrowser and acts like one. The concept has to work equally well 
for people like us, as well as 5-year-olds and 95-year-olds.


- Do apps that are similar to webapps, like GMail. That's a quick 
way to compare. Don't you think a 50k GMail look-a-like inside a 
REBOL browser running at native speeds would be _slightly_ impressive? 
Remember to say that you can serve 5 times more users with the same 
bandwidth. REBOL can help make raw numbers look better without much 
effort. Google would have to use it as a content platform. They have 
no other choice. :-) Chrome? What's that?


- Plugins suddenly are very flexible. You don't have plugins as in 
Firefox, but helper scripts that can enhance/change your browsing 
experience. 15k full screen document reader that prettifies plain 
text files? Sure thing. Blog posts presented in that would be much 
nicer to read. Out goes the PDF reader.


- Do apps that are completely out of the league of AJAX, such as 
multithreaded P2P systems. In fact, why not build P2P capabilities 
right in? Have different instances of the browser allow users to 
connect and chat, when they are visiting the same "Rebsite". It's 
sort of like going into a physical store and chatting with the other 
customers and you decide to exchange business cards. Initial contact 
without needing email. Do the same thing with chat support for an 
article that you bought at that  "rebsite". Current websites are 
almost completely anonymous. You don't feel you are entering a live 
community. Coded in REBOL/Services.


- Webpages are now REBOL scripts. In R3, scripts can be closed and 
encrypted, so you can't read the source and you can sell scripts 
and have them signed. The best you can do right now is some kind 
of code obfuscation.

- Windows, MacOSX and Linux version.


- "A webbrowser that directly supports OpenGL without obscure/limited 
3rd party plugins." Say that again in your head.


- It's very important that the public get to see that creating REBOL 
scripts for the browser is very similar to creating plain HTML pages. 
REBOL scripts can be served off a plain webserver. All the infrastructure 
is already there. Or how about serving scripts from the browser itself? 
AltME can both be a client and a server. It's that P2P thing again.

- Browser would run wherever R3 runs.


- Market it as Web 4.0. Market it as a direct competition to current 
webbrowsing.


- Browser would be a 500-600 kb downloadable exe that starts immediately 
without installation. From deciding to get it, to be using it to 
browse "Rebpages", it should not take more than 30-45 seconds.

- We need AltME in that browser (Altissimo?) as well as QTask.

For developers:


- It's easy to create an HTML file in notepad and display it in your 
favourite browser. It's going to be equally easy to create a REBOL 
script in notepad and see it running in your REBOL browser. A 5-year-old 
who has just learned to type, should be able to create a script and 
display it.

- One language for everything.


- Everything is free. You can start out with notepad. The barrier 
for creating content is about as low as it can get.


- You wanna code slow web 2.0 apps or fast web 4.0 apps? Hard choice, 
I know.

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.